home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1197 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.9 KB
  1. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  2. Subject: Memory Protection
  3. Date: Wed, 9 Mar 94 20:00:16 CST
  4.  
  5.  
  6.   Someone has told me that they have MultiTOS 1.04 and an 030 (a Falcon
  7. I think), but they have to rename MiNT to mintnp.prg to turn off memory
  8. protection because if an address is passed to the AES, memory protection
  9. can kill the AESSYS instead of killing the application that called the AES.
  10. I was wondering what the chances are that the AES was being viewed as an
  11. application by MiNT and MiNT was killing the AES for piddling with another
  12. application's RAM.  Is this possible?  I know that a second-hand bug 
  13. description is hard to deal with, especially when it may be the applications
  14. themselves.  
  15.  
  16.   However, along the same lines, I believe someone was talking about making
  17. pid 001 special like pid 000 (MiNT).  I think this is a good idea.  Killing
  18. MiNT has no effect (like trashing MiNT.000 from desktop), but I can easily
  19. kill GEM on my machine and crash the whole damn system!  By allowing pid 001
  20. global access to memory (so that it could not be killed by memory protection
  21. or such), could possibly solve the problem, but I don't think that is the
  22. right direction to take.
  23.  
  24.   I do think that pid 001 should not be "killable" from the desktop, and 
  25. if it does die, the system should reboot.  Also, all those errors that say
  26. to adjust the debug level and hit a key always lock up my machine - I'd
  27. rather have it reboot (cold boot) at that time and restart.  I would also
  28. like to reboot every time MiNt exits.  Perhaps an option in MiNT.CNF could
  29. control weither to use the normal errors, or to just reboot?  That would
  30. be an ideal option for plain MultiTOS users.
  31.  
  32.   On a totally unrelated issue, I think the fork should be non-blocking,
  33. using the slow memory copy method used in MINIX (only so that the call
  34. accomplishes the same on an 030 for a consistent interface), but use the 
  35. MMU on the 030.  Why can't an MMu be added to the 68000?  It should be
  36. possible I think.
  37.  
  38.  
  39.